A service-oriented architecture (“SOA”)-based networked computer system implements heterogeneous computing devices and software programs to provide distributed services. Any of these services can accept requests from a client irrespective of programming languages, hardware platforms, and locations on a network. Also, the services, such as a web services, exchange messages using standardized communication protocols, such as SOAP (Simple Object Access Protocol). SOAP is a protocol specification that defines a uniform way of passing XML-encoded data and defines a way to invoke remote processing using HTTP as a common transport protocol (or another transport protocol) as the underlying communication protocol. By using SOAP or any like protocol, a service requestor and a service provider can communicate across different platforms and different programs, so long as their interfaces are determinable, such as in accordance with an interface contract. Further, service-oriented architectures implement services without regard to the specific tasks or transactions that those services perform. Accordingly, developers of SOA-based systems can reuse existing services to implement newer and more sophisticated transactions.
But while the service-oriented architecture provides flexibility to build systems using existing services, the monitoring, managing, and controlling of SOA-based systems and their transactions can be difficult since any one service can receive and transmit messages for any number of unspecified transactions. Consequently, a manager of an SOA-based system cannot readily identify the participants in a specific transaction, thereby hindering the manager's ability to perform, for example, root-cause failure analysis, performance analysis, impact analysis (i.e., how modification of a service affects any number of transactions), and other like system diagnostics.
One approach to identify the transactions to which a particular service belongs alters the messages to insert keys that have a primary function of tracking dependencies among a specific grouping of services. Typically, the same key is inserted in to each message used to perform the transaction. A drawback to this approach is that altering a message to include a key can cause it to be deemed suspect and then discarded in accordance with some network security policies. Another drawback to this approach is that some service providers can be located outside the scope of a system manager's sphere of authority (e.g., services external to an enterprise), and as such, those outside services might not be equipped to process such keys that otherwise should be removed prior to messages arrival. Consequently, external services might fail if they cannot process the keys.
In view of the foregoing, it would be desirable to provide a mechanism for enhancing the functionality of existing services. Ideally, the technique would provide enhanced functionality to effectively characterize and relate service messages so as to detect, report and manage transactions and services in an SOA-based networked computer system.